\section{Introduction}

The Tactics programming language is designed to describe board games, such as \textit{Chess} and \textit{Contract Bridge}, with great concentration and simplicity. The play through of a board game can be abstracted as a series of stages, which is called \textit{events} in the Tactics. They form the foundation of this language, and makes the Tactics an \textit{event-based} language. The Tactics language extracts the most common data types and data structures for a board game, making the design process simple and intuitive to programmers or designers. Thus once they have conceptualized the definition of event, designers will be able to focus on the core procedure of a game. Finally with the translator tool provided with the Tactics, an interactive and extensible game system can be easily implemented.

\section{Event-Based}

\textit{Events}, or stages if you wish, in the Tactics are important components of any board game. The Tactics, as an \textit{event-based} language, aims at drawing designers’ attention to core rules and procedures of their games. On the other hand, such an event-based language brings considerable advantages in simulating the game play through, recording a very detailed history of events and providing essentials of incoming events. Last but not least, an event-based game system, built from the Tactics enables outstanding interactive feature that helps the users easily understand their roles in the game and the interactions with other gamers.

\begin{figure}[h]
\center\includegraphics[width=13cm]{event.png}
\caption{Events in a \textit{Contract Bridge} game}
\end{figure}

\subsection{Design Friendly}

We use the concept of event to describe the flow of a board game: each step in a board game is seen as an event in our language. The Tactics language aims at assisting board game designers who understand the procedure and rules of their games deeply, however only basic ideas of programming, to design and implement their board games in a simple and intuitive way.

\begin{quote}
Programmers who are users of our language may have experience in other programming languages, but their central expertise is the procedure and rules of their games in mind. They should not be annoyed by, say, memory allocation in C, or the abstraction of classes in Java. The abstraction of events is a natural way to describe the procedure of a game. For example, consider the card game \textit{Contract Bridge}, a programmer can define each stage of the game, say, \textit{dealing} where the deck is shuffled and drawn by players, or \textit{bidding} where each player in turn proposes a bid, as an event.
\end{quote}

\begin{figure}[h]
\center\includegraphics[width=11cm]{design.png}
\caption{\textit{Bidding} event flows in a \textit{Contract Bridge} game}
\end{figure}

Programmers can use event to encapsulate the each stage of a game and actions which would happen inside this stage. By utilizing the concept of event, our language not only makes the programming task easier, but also dramatically cuts down on bugs.

\begin{quote}
In our language, programmers are released from variable definition and parameter passing by utilizing event. Most programmers using other languages have experienced painful debugging process where they need to figure out why the variable value if out of their expectation, from thousands of lines of code. In our language, the scope of locally defined variables in an event is the defining event itself, which restricted the propagation of errors dramatically.
\end{quote}

\subsection{Traceable}

Game systems implemented in the Tactics Language provide programmers and players with traceable play \textit{histories}, as well as the idea of incoming events. For example, the histories can be displayed to the players during the game process, and the sketch outline of the game procedure can be displayed to the designer after the code is written.

\begin{quote}
Consider the game \textit{Contract Bridge}, each play of the game is recorded by the game system. After a play, players can view the history of the play to help them improve their skills. For game designer, as the code is written, he can view the essential procedure of the game to have a basic idea of the implemented game.
\end{quote}

\subsection{Interactive}

Our language was designed to support better interaction between player and game based on the language itself. By utilizing the concept of event, event-based interactions can be clearly defined by the programmer and prompted to the player. The integrated command-line interface within the language tool can be easily extended to a fully fledged GUI for better user experience -- since all the events will be honestly reported.

\begin{quote}
As an event-based implementation of a game system, all the in-process events in the procedure will be reflected on the user interface. In a \textit{Contract Bridge} game, a player would be clearly notified about every stage, \textit{dealing}, \textit{bidding}, \textit{player \emph{North} plays \emph{Diamond 7}}, etc.
\end{quote}

\begin{quote}
Consider the game \textit{Contract Bridge} again, suppose the programmer want to notify the players who the current player is, \textit{North}, \textit{East}, \textit{South}, or \textit{West}, in the \textit{bidding} event. The programmer can state the interaction like \texttt{output(current\_player, "whatever")} in the event, and when the event occurs the prompt is printed to the corresponding player's virtual screen. If the programmer want the game to get input from a player, she just need to state the interaction like \texttt{input(current\_player, bid)}.
\end{quote}

\section{Simple and Intuitive}

What game designers expertise in is the game procedure and rules, instead of programming. To ease their design procedure, the Tactics language provides them the very basic but most useful data types and containers. Such simplicity is contributed by the common features of board game such as the discrete attribute of objects. And the Tactics language can move its focus from efficiency to extreme simplicity due to a fairly limited amount of objects in a board game.

\begin{quote}
Most board games use discrete data types. We abstract all these data types as enumerations and integers.  Enumeration defines the possible attributes of an object class. In a card game, a designer may use \texttt{enum position \{North, East, South, West\}} to define the possible positions of a player, and \texttt{enum suits \{Clubs, Diamond, Hearts, Spades\}}, \texttt{enum points \{A, K, Q, J, N10, N9, N8, N7, N6, N5, N4, N3, N2\}} to define the possible suits and points of a card.
\end{quote}

\begin{quote}
Most board games use deck and hand cards, which are viewed as “multi-purpose” containers. This container structure is a combination of stack and list in other languages. The Tactics provides programmers with this containers for hand cards, deck, etc, and greatly simplifies their burden in data management.
\end{quote}

The Tactics still provides a composite type for the convenience of programmers to describe an object. For example, a card is the combination of suit and point, which are both enumerations. For both enumeration and composite of enumerations, it also provides default operations such as \texttt{random}.

\section{Future of the Tactics}

\begin{figure}[h]
\center\includegraphics[width=4cm]{future.jpg}
\caption{A Counterspell card}
\end{figure}

Recently, a large amount of card games with much more complex rules are invited to our lives. Their rules involve many card effects that not only determine the winning or losing of a round or two, but also the effect of other cards.
 
\begin{quote}
A typical example is a card from card game \textit{Magic the Gathering}. The act of countering-something means to entirely prevent it from taking effect. For example, if you play a \textit{Spell} and your opponent plays \textit{Counterspell}, your \textit{Spell}'s effect will never occur. Even more, the \textit{Counterspell} itself could be countered by another \textit{Counterspell} card.Our language has a great potential in describing these complex rules. A possible solution is to add \textit{event-driven} grammars -- when a target event happens, a new event would be added to incoming-event list to modify the procedure of the game, say, disabling the target \textit{Spell}.
\end{quote}

